Test Methods and Tools in Model - Based Function Development

There can be no doubt that electronics, and most particularly the software they contain, are the key to innovative and marketable functionality in modern vehicles However, a high level of reliability, safety, and quality in vehicle electronics is vital. There are currently two very important trends in automotive software development:  Controllers and functions are developed with the aid of simulation models. The C code needed for each specific target system is generated automatically on the basis of the models. Automatic production code generation has become a firm part of production development.  As software grows in complexity, and development cycles speed up, the software that is produced must be tested as early and as exhaustively as possible. Testing is now seen as a key element in quality assurance. Model-based development methods are shifting tests from code level to model level. In the earlier development phases especially, there is still great potential for complementing largely experimental development procedures with methods of model-based, automated testing. Typical test activities in model-based function development are model-in-the-loop, software-in-the-loop, and processor-in-the-loop simulation, with back-to-back methods based on them; black-box approaches such as the classification tree method; white-box methods with coverage measurement at model and code level; and formal verification. Combining model-based development with automated testing provides a powerful and efficient collection of tools and methods, from test project management to systematic test case generation, right through to automated test evaluation and final test report generation. This paper describes the processes involved and the methods that underlie them in the overall context of testing. Function Development with Automatic Production Code Generation Software development for electronic control units (ECUs) is increasingly being performed with model-based development tools such as MATLAB/ Simulink/Stateflow [(1)]. Once the specification has been produced with the aid of these tools, coding work can begin. Functions described in graphical form must be converted into C code and implemented on the ECU. Automatic production code generators are increasingly being used for this task. Today’s code generation methods are now so mature compared with the first generations of code generators that they are well able to bridge the gap between model-based function design and production software development. Production code generators like TargetLink [(2)] generate highly efficient, reliable, production-quality C code from a block diagram. They not only reduce development time, they also enhance the quality of the software and avoid human programming errors. Currently, automatic production code generators are primarily being used for new functional software components, in other words, control functions, in electronic control units (ECUs). The hardware-related software and the software infrastructure are handcoded. As the bulk of ECU software consists of function code, using automatic production code generators has rapidly grown in importance. TargetLink, for example, is now breaking through into widespread use in rollouts for major development projects. As the focus of development activities shifts from code level to model level, followed by automatic production code generation, testing at model level becomes essential. There is currently a clear trend towards applying the methods and approaches of classic software testing to model-based development. Basic Aspects of Testing Testing is a quality assurance and quality enhancement activity performed with the aim of finding errors. Testing is easy to learn and can be applied to even very complex systems. Although testing can be fairly expensive, the cost-benefit ratio is usually very positive. Testing is performed for validation or verification, depending on the test objective. Validation relates to the requirements established for the system under development. The requirements can be functional, i.e., relating to the actual purpose of the system, or nonfunctional, i.e., relating to performance, real time, memory consumption, etc. Verification means testing a test object against its specification. The specification describes the technical requirements that the object has to meet; these generally relate to the interfaces and to how the object must behave at the interfaces. The test object can be on any system level (unit, module, component, subsystem), depending on the level to which the specification applies and at which it is tested. Verification itself does not prove that the test object complies with the original system requirements, as the specification itself may be faulty. There is a wide variety of methods available for testing, which can be classified according to the scheme shown in Figure 1. There is a basic difference between static and dynamic testing. In dynamic testing, the test object is executed, while in static testing, it is not. Formal verification is a further method class. The following discussion focuses primarily on dynamic testing and formal verification, as these are the approaches mainly used in model-based development.